Methods and Systems to Communicate Information

ABSTRACT

There is provided a method and system to communicate information. The system receives a first query that contains a first constraint and retrieves a first plurality of data items from a database based on the first query. Next, the system generates a first distribution based on the first plurality of data items, the first distribution utilizing a first plurality of domains that are used to identify data items. Next the system generates a second distribution based on a plurality of requests to view a second plurality of data items. Next the system generates a third distribution based on the first distribution and the second distribution. Finally, the system generates distribution data to be included within an interface, the interface to include at least one interface element that is positioned on the interface based on the third distribution, the at least one interface element to respectively represent at least one domain.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.11/478,666, filed on Jun. 30, 2006 which claims the priority benefits ofU.S. Provisional Application No. 60/743,256, filed Feb. 9, 2006 and U.S.Provisional Application No. 60/781,521, filed Mar. 10, 2006, and U.S.Provisional Application No. 60/745,347, filed Apr. 21, 2006, all ofwhich are incorporated herein by reference in their entirety.

TECHNICAL FIELD

An embodiment relates generally to the technical field of datacommunications and, in one example embodiment, to methods and systems tocommunicate information.

BACKGROUND

A user searching an information resource (e.g., database) may encounterchallenges. One such challenge may be that a search mechanism (e.g., asearch engine) that is utilized to search the information resource maypresent search results that are of no interest to the user. For example,the search mechanism may respond to a query from the user with numerousdata items that cover a wide spectrum. The user may experiment by addingand removing constraints from the query, however, such experimentationmay be time consuming and frustrate the user. Another challenge may bethat the search mechanism fails to organize search results on a specificinterface in a way that is meaningful to the user.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment is illustrated by way of example and not limitation in thefigures of the accompanying drawings, in which like references indicatesimilar elements and in which:

FIG. 1 is a diagram depicting a peak distribution, according to oneexample embodiment;

FIG. 2 is a diagram depicting a hills distribution, according to oneexample embodiment;

FIG. 3 is a diagram depicting a flat distribution, according to oneexample embodiment;

FIG. 4 is a network diagram depicting a system, according to one exampleembodiment, having a client-server architecture;

FIG. 5 is a block diagram illustrating modules and engines, according toan embodiment;

FIG. 6 is a block diagram illustrating an information storage andretrieval platform, according to an embodiment;

FIG. 7 is a diagram illustrating a domain structure, according to oneembodiment;

FIG. 8 is a table illustrating sell-side data and buy-side data,according to one embodiment;

FIG. 9 is a diagram illustrating rules, according to an embodiment;

FIG. 10 is a diagram illustrating a canonical matching concept,according to an embodiment;

FIG. 11 is a diagram illustrating a set of requests, according to oneembodiment, that may cause the storage of navigation information;

FIG. 12 is a block diagram illustrating databases, according to anembodiment;

FIG. 13 is a block diagram illustrating classification information,according to an embodiment;

FIG. 14 is a block diagram illustrating a data item, according to anembodiment;

FIG. 15 is a block diagram illustrating a search index engine, accordingto an embodiment;

FIG. 16 is a block diagram illustrating a data item search information;

FIG. 17 is a block diagram illustrating a supply work area, according toan embodiment;

FIG. 18 is a block diagram illustrating demand data indexes, accordingto an embodiment;

FIG. 19 is a block diagram illustrating the demand work area, accordingto an embodiment;

FIG. 20 is a block diagram illustrating supply histograms, demandhistograms and total coverage histograms;

FIG. 21 is a flow chart illustrating a method to communicateinformation, according to an embodiment;

FIG. 22 is a flowchart illustrating a method, according to an embodimentto generate supply histograms;

FIG. 23 is a flowchart illustrating a method, according to anembodiment, to generate demand histograms;

FIG. 24 is a flowchart illustrating a method, according to anembodiment, to generate interface information;

FIG. 25 is a flowchart illustrating a method to generate distributiondata;

FIGS. 26-29 are diagrams illustrating user interfaces, according to anembodiment;

FIG. 30 is a block diagram of a machine, according to an exampleembodiment, including instructions to perform any one or more of themethodologies described herein.

DETAILED DESCRIPTION

Methods and systems to communicate information are described. In thefollowing description, for purposes of explanation, numerous specificdetails are set forth in order to provide a thorough understanding ofthe present disclosure. It will be evident, however, to one skilled inthe art that the subject matter of the present disclosure may bepracticed without these specific details.

A system may communicate information by generating an interface based onsupply information and demand information. With regard to the supplyinformation, the system may receive a first query that is entered by auser, identify matching data items, and maintain a set of data itemcounts for each domain. For example, in response to the first query, thesystem may find matching data items that may be identified or browsedaccording to product domain(s) (e.g., shoes), aisle domain(s) (e.g.,footwear), and department domain(s) (e.g., apparel), where a departmentdomain may include aisle domain(s) and/or product domains, an aisledomain may include product domain(s), and a product domain may includedata items. Continuing with the example, if a data item is found in aProduct C domain (e.g., shoes) that is organized under a hierarchy ofdomains (e.g., Department A—apparel, Aisle B—footwear, Product C—shoes),then the data item counts associated with the Department A, Aisle B andProduct C domains may be incremented by one. Domains with high data itemcounts may be determined to be of interest to the user.

With regard to the demand information, the system may read navigationinformation that is historical for queries that contains constraintsthat correspond to the first query over a predetermined period of time.Specifically, the system maintains navigation information in the form ofview data item counts according to domains, the view data item countsbeing incremented responsive to a user viewing a data item. For example,if a user previously entered a second query that contains constraintsthat correspond to the first query, selected the domain C and viewed adata item, then the view data item count corresponding to the domain Cmay be incremented by one. The view data item counts may be incrementedover a predetermined period of time (e.g., seven days) and then madeavailable as navigation information to generate demand information. Forexample, navigation information collected for the previous week may bemade available as navigation information to generate demand informationin the present week. Domains with high data item counts may bedetermined to be of interest to the user.

The system may maintain the supply information in the form of a producthistogram (e.g., percent of data items distributed over multiple productdomains), an aisle histogram (e.g., percent of data items distributedover multiple aisle domains), and a department histogram (e.g., percentof data items distributed over multiple department domains). The systemmay maintain the demand information in a similarly structured set ofhistograms.

The system may generate total coverage histograms including totalcoverage information based the supply information that is included inthe supply histograms and the demand information that is included in thedemand histograms. Specifically, the system may generate a totalcoverage histogram including total coverage information for productdomains, total coverage information for aisle domains, and totalcoverage information for department domains. The system may compare thetotal coverage histograms to predetermined distributions including apeak distribution 2, a hills distribution 4, and a flat distribution 6to identify the type of user interface to generate.

FIG. 1 is a diagram depicting the peak distribution 2, according to oneexample embodiment. The peak distribution 2 shows a peak with respect toa single domain B. The peak distribution 2 may be a predetermineddistribution that is compared with the total coverage histograms todetermine whether the total coverage histogram includes total coverageinformation exhibiting the peak distribution 2. For example, if thesystem detects a peak distribution 2 in a total coverage histogramincluding total coverage information for product domains, then thesystem may generate a product user interface that includes a singleproduct domain based on the position of the peak in the total coveragehistogram.

FIG. 2 is a diagram depicting the hills distribution 4, according to oneexample embodiment. The hills distribution 4 shows hills with respect tomultiple domains. The hills distribution 4 may be a predetermineddistribution that is compared with total coverage histograms todetermine whether the total coverage histogram includes total coverageinformation exhibiting the hills distribution 4. For example, if thesystem detects a hills distribution 4 in a total coverage histogramincluding total coverage information for product domains, then thesystem may generate a cross-product user interface that includesmultiple product domains based on the respective position of the hillsin the total coverage histogram.

FIG. 3 is a diagram depicting the flat distribution 6, according to oneexample embodiment. The flat distribution 6 is flat with respect tomultiple domains. The flat distribution 6 may be a predetermineddistribution that is compared with total coverage histograms todetermine whether the total coverage histogram includes total coverageinformation exhibiting the flat distribution 6. For example, if thesystem detects a flat distribution 6 in a total coverage histogramincluding total coverage information for product domains, then thesystem may attempt to detect peak, hills, and flat distributions fortotal coverage histograms associated with aisle domains. If, on theother hand, the system detects the flat distribution 6 with regard toaisle domains then the system may attempt to detect the peakdistribution for total coverage histograms associated with thedepartment domains.

A system may further communicate information by generating an interface.For example, the interface may include a user interface (e.g.,cross-product user interface, cross-aisle user interface,cross-department user interface) that includes user interface elementsrepresenting domains that may be positioned on the user interface basedon the supply and demand information. In one embodiment, the systemgenerates a user interface that includes user interface elements thatmay be positioned on the user interface in descending order proceedingfrom a highest total coverage information to the lowest total coverageinformation. For example, the system may position user interfaceelements representing departments (e.g., from highest to lowest totalcoverage) until a predetermined total coverage threshold (eightypercent) is reached or until a predetermined number of user interfaceelements threshold (e.g., ten), representing departments, may have beenpositioned on the use interface. In one embodiment, the predeterminedtotal coverage threshold and/or the predetermined number of userinterface elements threshold may be configurable. Other examples mayinclude other types of elements (e.g., audio interface elements, machineinterface elements, media interface elements) that may be positioned, asdescribed above, on other types of interfaces (e.g., audio interface,machine interface, media interface).

FIG. 4 is a network diagram depicting a system 10, according to oneexample embodiment, having a client-server architecture. A commerceplatform or commerce server, in the example form of an informationstorage and retrieval platform 12, provides server-side functionality,via a network 14 (e.g., the Internet) to one or more clients. FIG. 4illustrates, for example, a web client 16 (e.g., a browser, such as theInternet Explorer browser developed by Microsoft Corporation of Redmond,Washington State), and a programmatic client 18 executing on respectiveclient machines 20 and 22.

Turning to the information storage and retrieval platform 12, anapplication program interface (API) server 24 and a web server 26 arecoupled to, and provide programmatic and web interfaces respectively to,one or more application servers 28. The application servers 28 host oneor more modules 30 (e.g., modules, applications, engines, etc.). Theapplication servers 28 are, in turn, shown to be coupled to one or moredatabase servers 34 that facilitate access to one or more databases 36.The modules 30 provide a number of information storage and retrievalfunctions and services to users that access the information storage andretrieval platform 12.

While the system 10 shown in FIG. 4 employs a client-serverarchitecture, the present disclosure is of course not limited to such anarchitecture, and could equally well find application in a distributed,or peer-to-peer, architecture system. The various modules 30 may also beimplemented as standalone software programs, which do not necessarilyhave networking capabilities.

The web client 16 may access the various modules 30 via the webinterface supported by the web server 26. Similarly, the programmaticclient 18 accesses the various services and functions provided by themodules 30 via the programmatic interface provided by the API server 24.The programmatic client 18 may, for example, be a seller application(e.g., the TurboLister application developed by eBay Inc., of San Jose,Calif.) to enable sellers to author and manage data items or listings onthe information storage and retrieval platform 12 in an off-line manner,and to perform batch-mode communications between the programmatic client18 and the information storage and retrieval platform 12.

FIG. 5 is a block diagram illustrating the modules 30, according to anembodiment. The modules 30 include a communication module 40, a coveragemodule 42, a domain sort module 44, a processing module 46, aclassification service engine 48, a scrubber module 50, a query engine52, a search index engine 54, a demand data engine 56, and a listingmodule 74.

The communication module 40 may receive a query from the client machine22, 20 which may include one or more constraints (e.g., keywords,categories, information specific to a type of data item, otherwisereferred to as an item-specific, etc.). The communication module 40 mayinteract with the query engine 52, the search index engine 54, thedemand data engine 56, and the coverage module 42 to process the query.The communication module 40 may receive aspect-value pairs that may beextracted from the query responsive to processing the query. Further,the communication module 40 may construct a transformed query based onthe query received from the client machine 20, 22 and may communicatethe interface (e.g., user interface) to the user at the client machines22, 20.

The coverage module 42 may generate a total coverage histogram based oncorresponding supply histograms and demand histograms. For example, thecoverage module 42 may generate a total coverage histogram associatedwith product type domains based on a supply histogram and demandhistogram both associated with product type domains. The coverage module42 may generate total coverage histograms for product type domains,aisle type domains and department type domains. In addition, thecoverage module 42 may generate interface information by comparingdistributions of the total coverage information with the predeterminedpeak, hills, and flat distributions 2,4 and 6.

The domain sort module 44 may generate distribution data that maydetermine the position (e.g., order) of interface elements (e.g., userinterface elements, audio interface elements, media interface elements,machine interface elements) that represent domains for presentation onan interface (e.g., user interface, audio interface, media interface,machine interface) that includes multiple domains (e.g., cross-domainuser interface). For example, the domains of greatest interest to theuser may be represented at the most prominent positions on across-domain user interface with user interface elements.

The processing module 46 may receive classification information andmetadata information that may be authored with a classification andmetadata tool. The processing module 46 may publish the classificationinformation and metadata information to backend servers that may hostthe query engine 52, the search index engine 54, and the classificationservice engine 48.

The classification service engine 48 may apply domain rules and aspectrules to data items. The classification service engine 48 may applydomain rules to identify one or more domain-value pairs (e.g., ProductType=Women's Shoes) that may be associated with the data item. Theclassification service engine 48 may further apply the aspect rules toidentify aspect-value pairs (Brand=Anne Klein) that may be associatedwith the data item. The classification service engine 48 may apply thedomain and aspect rules to data items or listings as they are added tothe information storage and retrieval platform 12, or responsive to thepublication of new rules (e.g., domain rules, aspect rules).

The scrubber module 50 may process data items responsive to theinformation storage and retrieval platform 12 receiving the data itemsfrom the client machines 20, 22. For example, the scrubber module 50 mayuse the services of the classification service engine 48, as previouslydescribed, to apply domain rules and aspect rules to the data item. Thescrubber module 50 may further store the data item, with the associateddomain-value pairs and aspect-value pairs in a database 36 as itemsearch information. Further, the scrubber module 50 pushes or publishesitem search information over a bus in real time to the search indexengine 54.

The query engine 52 includes an aspect extractor module 58,classification information 49, metadata service module 60, and metadatainformation 62. The aspect extractor module 58 may receive a query fromthe communication module 40 and apply aspect rules to extractaspect-value pairs from the query. The aspect extractor module 58 mayfurther communicate the aspect-value pairs to the communication module40.

The metadata service module 60 may communicate metadata information tothe communication module 40 based on the query that is received from thecommunication module 40. The metadata information may include metadatathat the communication module 40 may use to format and generate theinterface (e.g., user interface).

The search index engine 54 may include search indexes 64, data itemsearch information 66 (e.g., including data items and associateddomain-value pairs and aspect-value pairs), and a supply work area 68.The search index engine 54 may receive the transformed query from thecommunication module 40 and utilize the search indexes 64 to identifydata items based on the transformed query. The search index engine 54may further communicate the found data items to the communication module40. The search index engine 54 is also shown to include a supply workarea 68 that may be used to generate histograms based on the data itemsearch information 66 associated with the found data items.

The demand data engine 56 includes demand data indexes 70 and a demandwork area 72. The demand data engine 56 may receive a pretransformedquery from the communication module 40 and use the pretransformed queryto search the demand data indexes 70 to identify navigation data thatmay be associated with previously received queries with constraints thatcorrespond to the constraints of the pretransformed query. For example,the navigation data may include a selection of a user interface that maybe associated with a domain (e.g., product type=shoes) that preceded aselection of a data item thereby suggesting a preferred domain to viewthe data item. The demand data engine 56 may further generate demandhistograms based on the navigation data.

The listing module 74 may receive information from a client machine 20or 22 and store the information as a data item in the database 36.

FIG. 6 is a block diagram further illustrating the information storageand retrieval platform 12, according to an embodiment. For example, theinformation storage and retrieval platform 12 may be embodied as anetwork-based marketplace (e.g., eBay, the Worlds Online Marketplacedeveloped by eBay Inc., of San Jose, Calif.) that supports thetransaction of data items or listings (e.g., goods or services) betweensellers and buyers. In one embodiment, the information storage andretrieval platform 12 may receive information from sellers that describethe data items that may subsequently be retrieved by potential buyers orbidders.

Rules Generation

At operation 80, a category or data manager may utilize a classificationand metadata tool to author rules that may include classification rules(e.g., domain rules and aspect rules) and metadata rules that may bereceived by a processing module 46 on the information storage andretrieval platform 12.

At operation 82, the processing module 46 may store the rules in thedatabase 36 in the form of classification information and metadatainformation.

At operation 84, the processing module 46 may publish the rules over abus to a query engine 53, a metadata service module 60, and aclassification service engine 48. For example, the processing module 46may publish the rules in real-time to facilitate the addition of newrules or the modification of existing rules while the informationstorage and retrieval platform 12 may be operating. In one embodiment,the processing module 46, query engine 52, metadata service module 60and classification service engine 48 may communicate with each otherover a bus that utilizes publish/subscribe middleware and databaseaccess software. In one embodiment the middleware may be embodied asTIBCO RENDEZVOUS™, a middleware or Enterprise Application Integration(EAI) product developed by Tibco Software, Inc. Palo Alto, Calif.

Data Item Generation

At operation 90, an author or publisher (e.g., a seller, user, etc.)enters information including item information into a client machine 20.The client machine 20 may communicate the item information to theinformation storage and retrieval platform 12 where the item informationmay be stored as a data item 65 in the database 36. The item informationentered by the user may include keywords in a title/description, one ormore categories in which to list the data item 65, and one or moreitem-specifics (e.g., color=blue).

At operation 92, a scrubber module 50 may read the data item 65 andutilize the services of the classification service engine 48 (operation94). The classification service engine 48 may apply domain specificrules to the data item 65 to identify one or more domains (e.g., producttype, aisle, department, etc.) and aspect-value pairs (e.g.,Brand=Nike). For example, the classification service engine 48 mayutilize a rule that includes a condition clause and a predicate clause.The classification service engine 48 may apply the condition clause tothe data item 65 (e.g., Title, description, category, item-specific,etc.) and if the condition evaluates TRUE, then the correspondingpredicate clause may be associated with the data item 65. For example, aseller may enter a data item 65 that includes Category=“Women's Shoes”,Title=“AK Size 8 Black Pumps” and the classification service engine 48may apply the rules to the data item 65 to identify one or moreapplicable domains that may be respectively stored as one or moredomain-value pairs with the data item 65 (e.g., if category=“Women'sShoes” then product type=Shoes, aisle=shoes, department=apparel).Further, the classification service engine 48 may apply rules toidentify one or more aspect-value pairs that may be associated with thedata item 65 (e.g., if Title=black then color=black, etc.) as data itemsearch information 66, The classification service engine 48 may, in anexample embodiment, assign only canonical values to the value of anaspect-value pair. For example, the seller may enter any of thefollowing strings “A Klein”, “Anne Klein” and “AK”; however, in eachcase, the classification service engine 48 may associate an aspect-valuepair with the same canonical value, Brand=“Anne Klein.”

At operation 96, the scrubber module 50 may store the data item 65,domain value-pairs, and aspect-value pairs as data item searchinformation 66 in the database 36.

At operation 98 the scrubber module 50 pushes or publishes the data itemsearch information 66 over a bus in real time to a search index engine54 that may store the data item search information 66 and update searchindexes 64 based on the data item search information 66. For example,the search index engine 54 may add a data item identification number toappropriate search indexes 64 that may be associated with keyword(s) oraspect-value pairs in the data item 65. The scrubber module 50 andsearch index engine 54 may communicate with each other over a bus thatutilizes publish/subscribe middleware and database access software. Inone embodiment the middleware may be embodied as TIBCO RENDEZVOUS™, asdescribed above.

Query Time Operations

At operation 100, a user may enter a query that includes different typesof constraints including a keyword constraint, an item-specificconstraint, and a category constraint. The query may be received by acommunication module 40 at the information storage and retrievalplatform 12.

At operation 102, the communication module 40 may communicate the queryto the query engine 52, at a back end server 103 that may include theaspect extractor module 58 and the metadata service module 60. Theaspect extractor module 58 may apply the aspect rules to the query toextract aspect-values from the query that may be associated with aproduct type. For example, the query “A Klein shoes size 8 black” maycorrespond to the aspect-value pairs color=black, brand=anne klein,size=8 IN product type=shoes. Further, the aspect extractor module 58may assign the same canonical values that were assigned by theclassification service engine 48, as described below. Indeed, the aspectextractor module 58 may utilize a sub-set of the same aspect rules thatwere utilized by the classification service engine 48.

At operation 104, the aspect extractor module 58 may communicate theextracted aspect-value pairs to the communication module 40. Further,the metadata service module 60 may communicate metadata information 62to the communication module 40. The communication module 40 may utilizethe extracted aspect-value pairs to construct a transformed query. Forexample, the transformed query may include keywords from the query andaspect-value pairs extracted from the query. In addition, thecommunication module 40 may cache the metadata for subsequentconstruction of the interface (e.g. user interface).

At operation 106, the communication module 40 communicates thetransformed query to the search index engine 54 at the back end server103. The search index engine 54 may utilize the transformed query toretrieve data items 65 which may subsequently be utilized by the searchindex engine 54 to generate supply histograms. The search index engine54 retrieves the data items 65 by utilizing the search indexes 64. Forexample, the search index engine 54 may utilize the keywords constraints(e.g., keywords) in the transformed query to retrieve itemidentification numbers from search indexes 64 that correspond to thekeywords. Further, the search index engine 54 may utilize theaspect-value pairs in the transformed query to retrieve itemidentification numbers from search indexes 64 that correspond to theaspect-value pairs.

The search index engine 54 may utilize the retrieved data items 65 togenerate supply histograms associated with products, aisles anddepartments. The supply histogram may include multiple entries of supplyinformation, for example in the form of a percent supply coverage thatmay be associated with each domain.

At operation 108, the search index engine 54 may communicate theretrieved data items 65 and the supply histograms to the communicationmodule 40.

At operation 110, the communication module 40 communicates the original(e.g., pretransformed) query to the demand data engine 56. The demanddata engine 56 utilizes the pretransformed query to generate a demandside product histogram, a demand side aisle histogram, and a demand sidedepartment histogram by utilizing navigation information that ishistorical (e.g., a database of network events that describe recordeduser activity).

At operation 112, the demand data engine 56 may communicate the demandhistograms to a coverage module 42 on a front end server 101. Thecoverage module 42 may generate total coverage histograms based oncorresponding supply histograms and demand histograms. For example, inone embodiment, the percent supply coverage associated with each domainin a supply histogram may be respectively added to the percent demandcoverage associated with each domain in a demand histogram and therespective results may be divided by two (e.g., an average) to yield atotal coverage histogram. Other embodiments may use different operationsto combine the supply information and demand information.

Next, the coverage module 42 may utilize the total coverage histogramsto generate interface information that may determine the type of userinterface to present to the user. For example, if the total coveragehistogram associated with products match the predetermined peakdistribution 2 then the coverage module 42 may generate product userinterface information (e.g., one product) where the product is selectedbased on the position of the peak. On the other hand, if the totalcoverage histogram associated with products indicates multiple hills,then the coverage module 42 may generate cross-product user interfaceinformation (e.g., multiple products) where the multiple products may beidentified based on the position of the hills. Finally, if the totalcoverage histogram associated with products is flat, then the coveragemodule 42 may bubble up to the total coverage histogram associated withaisles to determine the interface information to generate. If the totalcoverage histogram associated with aisles is flat, then the coveragemodule 42 may utilize the total coverage histogram associated withdepartments to determine the interface information to generate (e.g.,single department or multiple departments).

Finally, if a cross-domain display (e.g., multiple products, aisles, ordepartments) has been selected, then a domain sort module 44 maygenerate domain distribution data that may determine the order of thedomains for presentation on the display where the domains of greatestinterest to the user may be presented in the most prominent positions.For example, in one embodiment the domain sort module 44 may use a totalcoverage department histogram to display departments in descending order(e.g., sorted from highest to lowest percent total coverage) until afirst predetermined threshold (maximum cumulative coverage—eightypercent) is reached or until a second predetermined threshold (maximumnumber of domains—ten) is reached.

At operation 114, the communication module 40 may communicate theinterface (e.g., user interface) and the found data items 65 to theclient machine 20 where they are displayed to the user (e.g. buyer orbidder).

FIG. 7 is a diagram illustrating a domain structure 120, according toone embodiment. The domain structure 120 is shown to include buy-sidedata 122. and sell-side data 124. The sell-side data 124 is shown toinclude categories 126 that have been selected by an author of the dataitem 65 to categorize the data item 65 on the information storage andretrieval platform 12. For example, the author may have selected one ormore categories 126 that may include collectibles, jewelry and watches,etc. The buy-side data 122 is shown to include product domains 132(e.g., Belts, Watches, Handbags, etc.), aisle domains 130 (e.g., Women'sAccessories, Women's Clothing, Women's Bottoms, etc.) and a departmentdomain 128 (e.g., Apparel and Accessories). The previously describedrules may be used to associate sell side data 124 to the product, aisleand department domains 132, 130, 128. Further, the domains 132 130, 128may appear on interfaces (e.g., user interfaces) and communicated to theclient machines 20, 22 to enable a user to identify or browse the dataitems 65.

FIG. 8 is a table 148 further illustrating sell-side data 150 andbuy-side data 152, according to one embodiment. The sell-side data 150may be entered by an author or publisher of a listing or data item 65and stored in the data item 65 and, as described above. The sell-sidedata 150 may include a category 154, a title 156 and one or moreitem-specifics 158, 160. For example, the sell-side data 150 illustratesan author or publisher to have entered the category 154 “Women's Shoes”,the title 156 “AK Size 8 Black Pumps”, the item-specific 158 “Brand=ViaSpiga” and the item-specific 160 Size=8. The buy-side data 152 may beassociated. with the sell side data 150 via the rules, as previouslydescribed. Specifically, the condition clause in the rules may be usedto test sell-side data 150. If the rule evaluates TRUE then buy-sidedata 152 in the same column may be associated with the data item 65. Forexample, the buy-side data 152 is shown to include a productdomain-value pair 201 (e.g., product type=Women's Shoes), an aisledomain-value pair 201 (e.g., aisle type=Women's Clothing), a departmentdomain-value pair (e.g., department type=Apparel & Accessories) thatwere associated with the data item 65 based on the category 154 “Women'sShoes.” Note that multiple aspect brands 164 may be associated with thedata item 65 based on the title 156 and the item-specific 158.

FIG. 9 is a diagram illustrating rules 190, according to an embodiment.The rules 190 include domain rules 192 and aspect rules 196. The domainrules 192 and aspect rules 196 include a condition clause 198 (e.g.,trigger, Boolean expression, etc.) and a predicate clause 200. Thecondition clause 198 may include a Boolean expression that may evaluateTRUE or FALSE. In one embodiment the Boolean expression may be used toevaluate multiple fields in the data item 65. For example, a Boolean maybe used to evaluate the category 154, the title, 156, and anitem-specific 158 in a data item 65. Further, the Boolean expression mayinclude multiple operators (AND, OR, EXCLUSIVE OR, etc.). If thecondition clause 198 evaluates TRUE, then, the predicate clause 200 maybe associated with the data item 65.

The predicate clauses 200 associated with the domain rules 192 mayinclude a domain-value pair 201 (e.g., product type=Women's Shoes). Thedomain-value pair 201 may include a domain type 203 and a domain 205.The domain type 203 may describe the type of domain such as “ProductType”, “Aisle Type”, “Department Type”, etc. The domain 205 may describethe domain and may be limited to the corresponding domain type 203 suchas “Women's Shoes.” The domain-value pair 201 “product type=Women'sShoes” may further he used as a condition clause 198 to trigger theassociation of another domain-value pair 201. For example, the domainrule 194 is shown to evaluate TRUE if the data item 65 includes thepreviously associated domain-value pair 201 “Product Type=Women'sShoes.” If TRUE, then the domain-value pair 201 “aisle type =Women'sClothing” may also be associated with the data item 65. Accordingly, theassociation of one domain-value pair 201 to a data item 65 may triggerthe association of another domain-value pair 201. For example, a firstdomain rule 194 may be used to associate a product domain 132 forWomen's Shoes to an aisle domain 130 for Women's Clothing and a seconddomain rule 194 may be used to associate the aisle domain 130 forWomen's Clothing to a department domain 128 for Apparel and Accessories.

The predicate clauses 200 associated with the aspect rules 196 mayinclude an aspect-value pair 204 (e.g., color=ruby). For example, theaspect rule 197 is shown associate the aspect-value pair 204“color=ruby” to the data item 65 based on the condition clause 198, “ifTitle=Ruby.” The aspect-value pair 204 may include an aspect 206 such as“color” and a value 208 such as “ruby.” The aspect-value pair 204 (e.g.,color=ruby) be further used as a condition clause 198. For example, anaspect rule 199 may include the aspect-value pair 204 (e.g., color=ruby)to trigger the association of another aspect-value pair 204(“color=red”) to the data item 65. Accordingly, the association of oneaspect-value pair 204 to a data item 65 may be used to associate anotheraspect-value pair 204 to the data item 65. In addition, the aspect rules196 may include a condition clause 198 that includes a keyword 202. Forexample, an aspect rule 196 is shown to include the keyword 202 “ruby.”The keyword(s) 202 in the condition clause 198 may be used by the aspectextractor module 58 to associate keyword(s) 202 in a query that isreceived from the client machine 20 to aspect-value pairs 204.

FIG. 10 is a diagram illustrating a canonical matching concept 210,according to an embodiment. The canonical matching concept 210 may beused to identify a data item 65 with a query 212. The canonical matchingconcept 210 may use a value 208 that is canonical to represent othervalues 208. For example, the query 212 may he received from a clientmachine 20, 22 including the string, “AK.” The query 212 may beprocessed with an aspect rule 196 that may include a condition clause198 that includes multiple keywords 202 (If “Anne Klein” OR “Ann Klein”OR “A Klein” OR “AKNY” OR “AK”, etc.) to associate the canonicalaspect-value pair 204 “Brand=“Anne Klein” to the query 212.

Continuing with example, a data item 65 may be received from a seller atthe client machine 20, 22 and may include any of the illustrated stringsthat represent “Ann Klein.” For example, the title in the data item 65may contain “Anne Klein.” Continuing with the example, the data item 65may be processed with an aspect rule 196 that includes a conditionclause 198 that includes multiple keywords 202 (If title=“Anne Klein” OR“Ann Klein” OR “A Klein” OR “AKNY” OR “AK”, etc.) to associate thecanonical aspect-value pair 204 “brand=“Anne Klein” to the data item 65.

FIG. 11 is a diagram illustrating a set of requests 220, according toone embodiment. The set of requests 220 may cause the demand data engine56 to store navigation information in the demand data indexes 70. Theset of requests 220 may originate at the client machines 20, 22 and maybe received by the demand data engine 56 at the information storage andretrieval platform 12 that may register the occurrence of the set ofrequests 220. The set of requests 220 may include a query that mayinclude one or more constraints (e.g., keywords, categories,item-specifics, etc.), a request to view a domain (e.g., product domain166, aisle domain 168 or department domain 178) that may be received bythe demand data engine 56 prior to receiving a request to view a dataitem, and the request to view the data item 65. For example, atoperation 222, the demand data engine 56 may receive navigationinformation in the form of a query (e.g., “iPod”). At operation 224, thedemand data engine 56 may receive a request to view a cross domain page(e.g., including multiple product types). At operation 226, the demanddata engine 56 may receive a request to view the product domain 132“Portable Audio.” At operation 228, the demand data engine 56 mayreceive a request to view a data item 65. Responsive to receiving therequest to view the data item 65, the demand data engine 56 may registerthe request to view the data item 65 in the demand data indexes 70(e.g., increment a view data item count) corresponding to the query“iPod” and corresponding to the product domain 132 “Portable Audio”.

FIG. 12 is a block diagram illustrating databases 250, according to anembodiment. The databases 250 may include the data item 65, theclassification information 49 and the data item search information 256.The data item 65 may include information from the author of a listing ordata item 65 as entered from the client machine 22, 20. The data itemsearch information 66 includes the data item 65, and domain-value pairs201 and aspect-value pairs 204 that have been associated with the dataitem 65. The classification information 49 includes rules that may beapplied to queries and data items 65.

FIG. 13 is a block diagram illustrating the classification information49, according to an embodiment. The classification information 49 mayinclude multiple domain dictionaries 252, each associated with a producttype domain. Each domain dictionary 252 may include domain rules 192 andaspect rules 196. The domain rules 192, as previously described, may beused to associate a specific product type domain and/or aisle domainand/or department domain to the data items 65. The aspect rules 196 maybe used to associate aspect-value pairs 204 to the data items 65 thatmay be associated with the product type domain corresponding to thedomain dictionary 252.

FIG. 14 is a block diagram illustrating the data item 65, according toan embodiment. The data item 65 may include a title 258, a description260, one or more categories 262, one or more item-specifics 264, and adata item identification number 266. The title 258 may include keywordsentered by the user to describe the data item 65. For example, thepresent data item 65, as illustrated, shows a title “AK Size 8 BlackPumps.” The description 260 may be used to describe the data item 65that may be for sale or auction. The category 262 may be a categoryselected by the seller or author or publisher of the data item 65. Theitem-specific 264 may include item-specific information that may beassociated with the data item 65. In the present example, the data item65 may be a pair of shoes, and therefore an item-specific 264 for coloris appropriate. The data item identification number 266 uniquelyidentifies the data item 65 in the information storage and retrievalplatform 12.

FIG. 15 is a block diagram illustrating the search index engine 54,according to an embodiment. The search index engine 54 is shown toinclude the search index 64, the data item search information 66, andsupply work area 68. The search index 64 is further shown to includemultiple aspect-value pairs 204 and multiple keywords 202. Eachaspect-value pair 204 and keyword 202 is further illustrated asassociated with one or more data item identification numbers 266. Forexample, if a data item 65 was associated with the aspect-value pair 204“Brand=Anne Klein”, then the data item identification number 266corresponding to the data item 65 may be associated with theaspect-value pair “Brand=Anne Klein.” Also, for example, if a data item65 was associated with the aspect-value pair 204 “Color=Ruby”, then theaspect rule 196 “If title=Ruby then Color=Ruby” then the data itemidentification number 266 corresponding to the data item 65 may beassociated with the keyword 202 “Ruby” in the search index 64.

FIG. 16 is a block diagram illustrating the data item search information66. The data item search information 66 is shown to include multipledata item information 270 entries. Each data item information 270 entrymay be associated with a data item 65, one or more domain-value pairs201 and one or more aspect-value pairs 204.

FIG. 17 is a block diagram illustrating the supply work area 68,according to an embodiment. The search index engine 54 may utilize thesupply work area 68 to build supply histograms. The supply work area 68is shown to include a product work area 274 that may be used to buildthe supply histograms for all product domains 132 in the informationstorage and retrieval platform 12, an aisle work area 276 that may beused to build aisle supply histograms for all aisle domains 130 in theinformation storage and retrieval platform 12, and a department workarea 278 that may be used to build department supply histograms for alldepartment domains 128 in the information storage and retrieval platform12. Each of the work areas 274, 276, 278 may include data item counts280 and a total data item count 282, as illustrated with respect to theproduct work area 274. The data item count 280 may represent the numberof data items 65 found that may be associated with the correspondingdomain 205. The data item count 280 may be used by the search indexengine 54 to count the number of found data items 65 that may beassociated with the respective product type, aisle type or departmenttype domains 205. The search index engine 54 may sum or accumulate dataitem counts 280 in the supply work area 68 (e.g., product work area 274,aisle work area 276, department work area 278) to generate the totaldata item counts 282 for the respective work areas 274, 276, 278.

FIG. 18 is a block diagram illustrating the demand data indexes 70,according to an embodiment. The demand data indexes 70 may be used tostore navigation information and may include multiple demand indexes284. Each demand index 284 is shown to include a second query in theform of query keyword(s) 286. The query keywords 286 may be matchedagainst the keywords contained in a query as received from the clientmachine 20, 22. Each query keyword(s) 286 entry may be associated withmultiple domain demand data 287 entries. Each domain demand data 287entry may be associated with a domain type (e.g., product domain 132,aisle domain 130, and department domain 128) that supports entries forall domains 205 associated with the domain type. Each entry within thedomain demand data 287 includes a domain identifier 289, and a view dataitem count 290. The appropriate view data item count 290 may beincremented by the demand data engine 56 responsive to the detection ofa set of requests 220 that may include a query that matches the querykeywords 286, a request to view the domain 205 (e.g., product domain166, aisle domain 168 or department domain 178), and a request to view adata item 65. The specific view data item count 290 that may beincremented corresponds to the domain 205 associated with the request toview the domain that preceded the request to view the data item 65.Further, the view data item count 290 may be collected over a standardperiod of time (e.g., seven days, one month, etc.).

FIG. 19 is a block diagram illustrating the demand work area 72,according to an embodiment. The demand data engine 56 may utilize thedemand work area 72 to build demand histograms. The demand work area 72is shown to include a product work area 300 that may be used to builddemand histograms for all product domains 132 in the information storageand retrieval platform 12, an aisle work area 302 that may be used tobuild aisle demand histograms for all aisle domains 130 in theinformation storage and retrieval platform 12, and a department workarea 304 that may be used to build department demand histograms for alldepartment domains 128 in the information storage and retrieval platform12. Each of the work areas 300, 302, 304 may include a total view dataitem count 308, as illustrated with respect to the product work area300. The view data item counts 290 in the domain demand data 287 (e.g.,product domains or aisle domains or department domains) may be used bythe demand data engine 56 to generate the total view data item counts308 that may be associated with the respective product type, aisle typeor department type domains 205. For example, the demand data engine 56may sum or accumulate all of the view data item counts 290 within adomain demand area 287 (e.g., product domains or aisle domains ordepartment domains) to generate the total view data item counts 308 forthe respective work areas 300, 302, 304. Further, the total view dataitem count 308 may be used to generate demand information in the form ofa percent demand coverage that may be stored in a demand histogramaccording to domain 205 (e.g., view data item count 290/total view dataitem count 308).

Histograms

FIG. 20 is a block diagram illustrating supply histograms 320, demandhistograms 322 and total coverage histograms 324.

Supply Histograms

The supply histograms 320 may include a first distribution in the formof a product histogram 326, an aisle histogram 328 or a departmenthistogram 330. For example, the product histogram 326 may include thesupply information 331 (e.g., percent supply coverage) distributedacross the product domains 132 in the information storage and retrievalplatform 12. The aisle histogram 328 may include supply information 331(e.g., percent supply coverage) distributed across the aisle domains 130in the information storage and retrieval platform 12. The departmenthistogram 330 may include the supply information 331 (e.g., percentsupply coverage) distributed across the department domains 128 in theinformation storage and retrieval platform 12.

Demand Histograms

The demand histograms 322 may include a second distribution in the formof a product histogram 332, an aisle histogram 334, or a departmenthistogram 336. The product histogram 332 may include demand information333 (e.g., percent demand coverage) distributed across the productdomains 132 in the information storage and retrieval platform 12. Theaisle histogram 334 may include the demand information 333 (e.g.,percent demand coverage) distributed across the aisle domains 130 in theinformation storage and retrieval platform 12. The department histogram336 may include the demand information 333 (e.g., percent demandcoverage) distributed across the domains 128 in the information storageand retrieval platform 12. In one embodiment the demand information 333associated with a domain may be calculated only if supply information331 (e.g., non-zero value) exists for the corresponding domain.

Total Coverage Histograms

The total coverage histograms 324 may include a third distribution inthe form of a product histogram 338, an aisle histogram 340 or adepartment histogram 342. The product histogram 338 includes may includetotal coverage information 335 (e.g., percent total coverage)distributed across the product domains 132 in the information storageand retrieval platform 12. The aisle histogram 340 may include the totalcoverage information 335 (e.g., percent total coverage) distributedacross the aisle domains 130 in the information storage and retrievalplatform 12. The department histogram 336 may include the total coverageinformation 335 (e.g., percent total coverage) distributed across thedepartment domains 128 in the information storage and retrieval platform12.

FIG. 21 is a flow chart illustrating a method 400 to communicateinformation, according to an embodiment. Illustrated on the left is theclient machine 20; illustrated in the middle are operations performed bythe front-end servers 101; and illustrated on the right are operationsperformed by the backend servers 103. The method 400 commences atoperation 402 with the web client 16 at the client machine 20communicating a query that may be entered by a user. The query maycontain one or more constraints that may include keyword constraints,category constraints, and item-specific constraints. For example, theuser may enter the query with the following keywords 202, “AK shoesruby.”

At operation 404, at the front-end servers 101, the communication module40 may receive the query from the client machine 20 and at operation 406the communication module 40 may request aspect extraction and metadatainformation 62 based on the query.

At operation 408, the aspect extractor module 58 receives the query andextracts aspect-value pairs from the query based on aspect rules 196.For example, the aspect extractor module 58 may extract the aspect-valuepairs 204 “Brand=Anne Klein” and “Color=ruby.” Note that aspectextractor module 58 has generated canonical aspect-value pairs 204 basedon the query “AK shoes ruby.” In addition, the metadata service module60 may identify metadata. information 62 based on the query “AK shoesruby.” Finally, the aspect extractor module 58 may communicate theaspect-value pairs 204 “Brand=Anne Klein” and “Color=ruby” to thecommunication module 40 on the front-end server 101 and the metadataservice module 60 may communicate the appropriate metadata information62 to the communication module 40 on the front-end server 101.

At operation 410, at the front-end server 101, the communication module40 may generate a transformed query based on the query and extractaspect-value pairs 204. For example, the communication module 40 maygenerate the transformed query [“AK” AND “shoes” AND “ruby”] OR[“Brand=Anne Klein” AND “Color=ruby”].

At operation 420, the communication module 40 may request data items 65and supply histograms 320 based on the transformed query bycommunicating the transformed query to the search index engine 54.

At operation 422, the search index engine 54 may retrieve the data items65 based on the transformed query. Specifically, the search index engine54 may search the search indexes 64 based on the aspect-value pairs 204(e.g., “Brand=Anne Klein” AND “Color=ruby”) to identify matching dataitems 65 (e.g., found data items). Note that a matching data item 65 mayinclude both aspect-value pairs 204 to be considered a match. Further,the search index engine may identify a matching data item based on thekeywords in the transformed query (e.g., “AK” AND “shoes” AND “ruby”).Note that a matching data item 65 may be required to include all threekeywords 202 to be considered a match.

At operation 424, the search index engine 54 may generate supplyhistograms 320 (e.g., distributions) based on the found data items 65using the domains 205 that may be used to identify the data items 65, asdescribed further below. For example, the domains 205 may include theproduct, aisle and department domains 132, 130, 128 that may benavigated by buyers to find the data items 65. In addition, the searchindex engine 54 may communicate the distributions and the found dataitems 65 to the communication module 40 at the front-end server 101.

At operation 426, the communication module 40 may request demandhistograms 322 based on the query received from the client machine. Forexample, the communication module 40 may communicate the query “AK shoesruby.”

At operation 428, the demand data engine 56 may generate demandhistograms 322 (e.g., distributions) of requests to view data items 65across domains based on navigation information associated with thequery. For example, the demand data engine 56 may identify a demandindex 284 associated with constraints (e.g., query keywords 286 “AKshoes ruby”) that correspond to the constraints (e.g., keywords) in thequery “AK shoes ruby”, as described further below. Responsive toidentifying the demand index 284, the demand data engine 56 may add theview item counts 290 associated with a type of domain (e.g., productdomains or aisle domains or department domains) and store the sum as thetotal view item count 308 in the demand work area (e.g., product workarea 300, aisle work area 302, department work area 304). Next, thedemand data engine 56 may generate demand information 333 (e.g., percentdemand coverage) for the product histogram 332, the aisle histogram 334and the department histogram 336. For example, the demand data engine 56may generate demand information 333 for a product domain in the producthistogram 332 by dividing the view data item count 290 associated withthe product domain by the total view data count 308 associated with theproduct work area 400. Continuing with the example, the demand dataengine 56 may store the demand information 333 in the product histogram332 according to the product domain. Finally, the demand data engine 56may communicate the demand histograms 322 to the coverage module 42 onthe front-end servers 101. In one embodiment the demand information 333associated with a domain may be calculated only if supply information331 (e.g., non-zero value) exists for the corresponding domain.

At operation 430, the coverage module 42 may generate total coveragehistograms 324 based on the corresponding supply histograms 320 and thecorresponding demand histograms 322. In one embodiment, the coveragemodule 42 may generate an average for each domain 205 in the totalcoverage histogram 324, as previously described. Other embodiments maygenerate the total coverage histogram 324 in a different manner. Inanother embodiment, the coverage module 42 may scale each of the demandinformation 333 entries (e.g., percent demand coverage) in the demandhistograms 322 before generating averages for each domain 205. Forexample, the percent demand coverage entries in the demand histogram 322may be scaled by a factor of 1.2 before combining (e.g., averaging) theentries of the supply histogram 320 with the respective entries of thedemand histogram 322. Likewise the percent demand coverage entries inthe supply histogram 320 may also be scaled. In another embodiment thefollowing equation may be used to generate the total coverage histogram:

Total Coverage Information(X)=Demand Information(X)*[DEM WEIGHT]+SupplyInformation(X)*(1-DEMAND WEIGHT))

For example, the “Total Coverage Information” may include the totalcoverage information 335 for the domain 205 “X”; the “X” may include aspecific domain that may be a product domain 132, an aisle domain 130,or a department domain 128; the “Demand Information” may include thedemand information 333 for the domain “X”; the “DEMAND WEIGHT” mayinclude a weight between 0 and 1; and the “Supply Information” mayinclude the supply information 331 for the domain “X”.

At operation 432, the coverage module 42 generates interfaceinformation. The coverage module may generate interface information bycomparing the total coverage histograms 324 (e.g., product histogram338, aisle histogram 340, department histogram 342) with predetermineddistributions 2, 4, 6 to determine the type of interface information togenerate, as described further below.

At operation 434, the domain sort module 44 may generate distributiondata if the coverage module 42 generated interface information formultiple product domains or multiple aisle domains or multipledepartment domains (e.g., operations 432, method 498). The domain sortmodule 44 may generate the distribution data that may be utilized forselecting and positioning interface elements (e.g., user interfaceelements, audio interface elements, media interface elements, machineinterface elements) that may represent domains 205 (e.g., productdomains) on the interface (e.g., user interface, audio interface, mediainterface, machine interface) based on the total coverage histograms324. For example, domain sort module 44 may select and position userinterface elements for a cross-domain user interface (e.g., displayingmultiple domains based on a hills distribution), as described furtherbelow (e.g., method 530).

At operation 436, the communication module 40 may use the interfaceinformation and may use the distribution data to generate the interface.For example, the communication module 40 may use product user interfaceinformation to generate a product user interface or cross product userinterface information to generate a cross product user interface oraisle user interface information to generate an aisle user interface orcross aisle user interface information to generate a cross aisle userinterface or department user interface information to generate adepartment user interface or cross-department user interface informationto generate a cross-department user interface, In addition, thecommunication module 40 may use the distribution data to generate across-product or cross-aisle or cross-department user interfaces.Finally, the communication module 40 may communicate the generated userinterface to the client machine 20.

At operation 438, at the client machine 20, the web client 16 receivesand displays the user interface.

While the above described example embodiment includes the generation andcommunication of a user interface, it will readily be appreciated thatother embodiments may generate and communicate information to bepresented to a user, for example via a graphical user interfacegenerated at the client side, or in some other manner (e.g., an audiointerface, machine interface, media interface). As such, thecommunicated information may comprise, for example, eXtensible MarkupLanguage (XML) data that is processed and communicated to a user via aninterface.

Further, while the presentation of information has been described in thecontext of a client-server network environment, embodiments may bedeployed in a standalone computer system environment, or in apeer-to-peer network environment.

FIG. 22 is a flowchart illustrating a method 440, according to anembodiment, to generate supply histograms 320. The method 440 commencesat operation 450 with the search index engine 54 generating a list ofdata item identification numbers 266 based on the transformed query. Forexample, all data items identification numbers 266 associated with theaspect-value pairs 204 “Brand=Anne Klein” or “Color =ruby” in the searchindex 64 may be included on the list. In addition, all data itemidentification numbers 266 associated with the keywords “AK” AND “shoes”AND “ruby” in the search index 64 may be also be included on the list.

At operation 452, the search index engine 54 may read the next data iteminformation 270 from the data item search information 66 based on thedata item identification number 266 in the list.

At operation 454 the search index engine 54 reads the next domain-valuepair 201 in the data item information 270.

At operation 456, the search index engine 54 increments the data itemcount 280 that may be associated with the current domain 205 and atoperation 458 the search index engine 54 may increment a total data itemcount 282 associated with the domain type. For example, the domain typemay include a product, aisle, or department.

At decision operation 460, the search index engine 54 may determinewhether there are more domain-value pairs 201 in the data iteminformation 270. If there are more domain-value pairs 201, a branch ismade to operation 454. Otherwise a branch is made to decision operation462.

At decision operation 462, the search index engine 54 may determine ifthere are more data item identification numbers 266 in the list. Ifthere are more data item identification numbers 266, a branch is made tooperation 452. Otherwise a branch is made to operation 464.

At operation 464, the search index engine 54 may generate and storesupply information 331 in the form of percent supply coverage entries inthe supply histograms 320. For example, the search index engine 54 maydivide the data item count 280 for each of the domains 205 in therespective work areas 274, 276, 278 by the appropriate total data itemcount 282 (e.g., product, aisle, department) to generate a percentsupply coverage that may be stored according to domain 205 in the supplyhistograms 320 (e.g., product histogram 326, the aisle histogram 328 anddepartment histogram 330). In another embodiment, the communicationmodule 40 may generate and store supply information 331 in the form ofpercent supply coverage entries in the supply histograms 320.

At operation 466, the search index engine 54 communicates the supplyhistograms 326, 328, 330 to the communication module 40 and the processends.

FIG. 23 is a flowchart illustrating a method 470, according to anembodiment, to generate demand histograms 322. The method 470 commencesat operation 472 with the demand data engine 56 receiving the query asentered at the client machine 20. For example, the demand data engine 56may receive the query “AK shoes ruby.” At operation 474, the demand dataengine 56 may compare the constraints (e.g., keywords) in the query withthe constraints (e.g., query keywords 286) in the demand data indexes 70to identify a matching demand index 284. In one embodiment the demandindex 284 may include query keywords 286 (e.g., “AK shoes ruby”) thatcorrespond to the keywords “AK shoes ruby.” In another embodiment,multiple demand indexes 284 may be used to match each query keyword 286in the query (e.g., “AK” and “shoes” and “ruby”).

At operation 478, the demand data engine 56 adds the view data itemcount 290 associated with a domain to the appropriate total view dataitem count 308 in the demand data work area 72. For example, the demanddata engine 56 may add the view data item count 290 associated with aproduct domain to the total view data item count 308 in the product workarea 300.

At decision operation 479, the demand data engine 56 determines if thereare more domains 205 to process in the domain demand data 287 (e.g.,corresponding to products, aisles or departments). If there are moredomains 205, a branch is made to operation 480. Otherwise a branch ismade to decision operation 481.

At operation 480, the demand data engine 56 reads the next view dataitem count 290 (e.g., corresponding to the next domain) from the domaindemand data 287. At decision operation 481, the demand data engine 56determines if there is another domain demand data 287 (e.g., productdomains, aisle domain, or department domains). If there is more domaindemand data 287 a branch is made operation 482. Otherwise a branch ismade to operation 483.

At operation 482 the demand data engine 56 reads the next domain demanddata 287 (e.g., corresponding to products, aisles or departments).

At operation 483, the demand data engine 56 divides the current viewdata item count 290, corresponding to a domain, by the appropriate totalview data item count 308 (e.g., product work area 300, aisle work area302, department work area 304) to generate demand information 333.

At operation 484, the demand data engine 56 stores the demandinformation 333 according to domain in the appropriate demand histogram(e.g., product histogram 332 or aisle histogram 334 or departmenthistogram 336).

At decision operation 485, the demand data engine 56 determines if thereare more domains 205 to process in the domain demand data 287 (e.g.,corresponding to products, aisles or departments). If there are moredomains 205, a branch is made to operation 486. Otherwise a branch ismade to decision operation 487.

At operation 486, the demand data engine 56 reads the next view dataitem count 290 (e.g., corresponding to the next domain) from the domaindemand data 287. At decision operation 487, the demand data engine 56determines if there is more domain demand data 287 (e.g., productdomains, aisle domain, or department domains). If there is more domaindemand data 287 a branch is made operation 488. Otherwise a branch ismade to operation 489.

At operation 488 the demand data engine 56 reads the next domain demanddata 287 (e.g., corresponding to products, aisles or departments).

At operation 489, the demand data engine 56 communicates the demandhistograms 322 to the communication module 40 at the front-end servers101.

FIG. 24 is a flowchart illustrating a method 498, according to anembodiment, to generate interface information. In the present examplethe interface information generated is user interface information;however, it will be appreciated by those skilled in the art thatinterface information may also include machine interface information(e.g., SGML) to communicate with a machine (e.g., client, server, peerto peer), audio interface information (e.g., sound), or a mediainterface information (e.g., media). The method 498 commences atdecision operation 500 with the communication module 40 determining ifthe product histogram 338 exhibits the peak distribution 2. For example,the communication module 40 may compare the product histogram 338 (e.g.,percent total coverage) to a predetermined peak distribution 2. If theproduct histogram 338 matches the peak distribution 2, then a branch ismade to operation 502. Otherwise, a branch is made to decision operation504.

At operation 502, the communication module 40 generates product userinterface information based on the position of the peak in the producthistogram 338. For example, if product domains 132 A, B, and C wererespectively associated with percent total coverage of 10%, 80%, and 10%then product user interface information for product domain B may begenerated.

At decision operation 504, the communication module 40 determines if theproduct histogram 338 exhibits the hills distribution 4. For example,the communication module 40 may compare the product histogram 338 (e.g.,percent total coverage) to the hills distribution 4. If the producthistogram 338 matches the hills distribution 4 then, a branch is made tooperation 506. Otherwise, a branch is made to decision operation 508.

At operation 506, the communication module 40 generates cross-productuser interface information based on the position of the hills in theproduct histogram 338. For example, if the product domains 132 A, B, C,D, E, F were respectively associated with percent total coverage of 3%,30%, 3%, 30%, 4%, 30% then cross-product user interface information forproduct domains B, D, and F may be generated.

At decision operation 508, the communication module 40 may determine ifthe aisle histogram 340 exhibits the peak distribution. For example, thecommunication module 40 may compare the aisle histogram 340 (e.g.,percent total coverage) to the predetermined peak distribution 2. If theaisle histogram 340 matches the peak distribution 2, then a branch ismade to operation 510. Otherwise, a branch is made to decision operation512.

At operation 510, the communication module 40 generates aisle userinterface information based on the position of the peak in the aislehistogram 340. For example, if the aisle domains 130 A, B, and C wererespectively associated with percent total coverage of 10%, 80%, and 10%then the aisle user interface information for aisle domain B may begenerated.

At decision operation 512, the communication module 40 determines if theaisle histogram 340 exhibits the hills aisle distribution 4. Forexample, the communication module 40 may compare the aisle histogram 340(e.g., percent total coverage) to the hills distribution 4. If the aislehistogram 340 matches the hills distribution 4 then, a branch is made tooperation 514. Otherwise, a branch is made to decision operation 516.

At operation 514, the communication module 40 generates cross-aisle userinterface information. For example, if the product domains 132 A, B, C,D, E, F were respectively associated with the percent total coverages of3%, 30%, 3%, 30%, 4%, 30%, then cross aisle user interface informationfor aisle domains B, D, and F may be generated.

At decision operation 516, the communication module 40 determines if thedepartment histogram 342 exhibits the peak distribution 2. For example,the communication module 40 may compare the department histogram 342(e.g., percent total coverage) to the peak distribution 2. If thedepartment histogram 342 matches the peak distribution 2 then a branchis made to operation 518. Otherwise, a branch is made to operation 520.

At operation 518, the communication module 40 generates department userinterface information based on the position of the peak as determinedfrom the department histogram 342. For example, if the departmentdomains 128 A, B, and C were respectively associated with percent totalcoverage of 10%, 80%, and 10%, then department user interfaceinformation for department domain B may be generated.

At operation 520, the communication module 40 generates cross-aisledomain information user interface information and the process ends. Forexample, if the department domains 128 A, B, C, D, E, F wererespectively associated with percent total coverage of 3%, 30%©, 3%,30%, 4%, 30%, then cross department user interface information fordepartment domains B, D, and F may be generated.

FIG. 25 is a flowchart illustrating a method 530 to generatedistribution data, according to an embodiment. In the present examplethe distribution data is used to select and position user interfaceelements on a user interface; however, it will be appreciated by thoseskilled in the art that distribution data may be generated to select andposition machine interface elements for a machine interface (e.g.,SGML), audio interface elements fore an audio interface, media interfaceelements for a media interface, or some other type of interface. Themethod 530 commences at decision operation 532 with the domain sortmodule 44 determining if a cross-domain user interface (e.g., crossproduct user interface or cross aisle user interface or cross departmentuser interface) has been identified by the communication module 40 to begenerated. If a cross-domain user interface has been identified, abranch is made to operation 534. Otherwise, the process ends.

At operation 534, the domain sort module 44 sorts the total coverageinformation 335 entries in the total coverage histogram 324 (e.g.,product histogram 338 or aisle histogram 340, or department histogram342) into descending order (e.g., high to low). Each total coverageinformation 335 entry is associated with a domain 205. The domain sortmodule 44 maintains the association between the total coverageinformation 335 entry and the domain 205 while sorting. in oneembodiment, the total coverage information 335 entries may berepresented as percent total coverage, as previously described.

At operation 536, the domain sort module 44 registers the domain 205associated with the current total coverage information 335 for displayon the user interface. For example, the product domain 132 “Shoes” maybe associated with the current total coverage information 335.

At operation 538, the domain sort module 44 gets a user interfaceelement based on the current domain and increments a user interfaceelement counter 537. At operation 540, the domain sort module 44 addsthe total coverage information 335 associated with the current domain toa register that records cumulative coverage.

At decision operation 542, the domain sort module 44 determines if thecumulative coverage is greater than or equal to a predeterminedthreshold. If the cumulative coverage is greater or equal to thepredetermined threshold, then a branch is made to operation 550.Otherwise, a branch is made to decision operation 544. For example, thepredetermined threshold may be eighty percent.

At decision operation 544, the domain sort module 44 determines if theuser interface element counter 537 is equal to a predetermined threshold(e.g., maximum user interface elements on a cross-domain userinterface). In one embodiment the maximum user interface elements may beten. If the user interface element counter 537 is equal to thepredetermined threshold, then a branch is made to operation 550.Otherwise, a branch is made to decision operation 546.

At decision operation 546, the domain sort module 44 determines if thereis another total coverage information 335 entry in the total coveragehistogram 324 (e.g., product histogram 338 or aisle histogram 340 ordepartment histogram 342). If there is more total coverage information335, then a branch is made to operation 548. Otherwise, a branch is madeto operation 550. At operation 548, the domain sort module 44 reads thenext total coverage information 335 entry from the total coveragehistogram 324 (e.g., product histogram 338 or aisle histogram 340 ordepartment histogram 342).

At operation 550, the domain sort module generates other user interfaceelements for the user interface and communicates the user interfaceelements to the communication module 40.

FIG. 26 is a diagram illustrating a cross department user interface 560,according to an embodiment. The cross department user interface 560 maybe generated based on a hills distribution 4 and is shown to includeuser interface elements 562, 564, 566, and 568. The ten user interfaceelements 562 represent ten department domains 128 (e.g., Home & Garden,Toys, Apparel, etc.) that may appear on the user interface 560 from topto bottom according to descending and respectively associated totalcoverage information 335. The ten department domains 128 equal thepredetermined threshold of maximum user interface elements that may bedefined for a cross-domain user interface. Other embodiments may includeother predetermined thresholds. The user interface 560 illustrates thatthe predetermined threshold for maximum user interface elements (e.g.,ten) was reached before the predetermined threshold for cumulativecoverage information. The user interface elements 564 representdepartment domains 128 that were respectively associated with totalcoverage information 335 entries that were lower than the total coverageinformation 335 entries respectively associated with the user interfaceelements 562. The above remarks may also apply to the cross aisle userinterface and the cross product user interface. The user interfaceelements 562 and 564 representing the aisle domains 130 on the crossaisle user interface 560 and the user interface elements 562 and 564representing the product domains 132 on the cross aisle user interface560.

FIG. 27 is a diagram illustrating a cross department user interface 570,according to an embodiment. The user interface 570 is shown to includeuser interface elements 572, 574, 576, 578, 580 and 582. The three userinterface elements 572 respectively representing the Home & Garden,Toys, Apparel department domains 128. The three user interface elements572 appear on the user interface 570 from top to bottom according to adescending sort of respectively associated total coverage information335. The cross-department user interface 570 illustrates that thepredetermined threshold for maximum cumulative coverage was reachedbefore the predetermined threshold for maximum user interface elements.For example, the department domains 128 “Home & Garden”, “Toys” and“Apparel” may be respectively associated the total coverage information335 of 30%, 30%, 28%. The above remarks may also apply to the crossaisle user interface and the cross product user interface. The userinterface elements 572 and 574 representing the aisle domains 130 on thecross aisle user interface 570 and the user interface elements 562 and564 representing the product domains 132 on the cross aisle userinterface 570.

The eleven user interface elements 574 represent the “Video Games”,“Tickets”, “Health & Beauty”, “Sporting Goods”, “Music & MusicalInstruments”, “Coins”, “Movies”, “Collectibles”, “Jewelry & Watches”,“Books”, and “Crafts” department domains 128. The user interfaceelements 564 may be associated to total coverage information 335 of 3%,1%, etc. The user interface element 580 represents a query dialog boxthat includes a query “green” that may have been entered by a userthereby requesting the information storage and retrieval platform 12 tosearch for data items 65 that contain the keyword “green.” The userinterface element 582 represents a category selector 582 which is set tosearch “All Categories” for data items 65. The user interface element576 represents a domain name (e.g., “Home & Garden”, “Toys”, etc.) andthe user interface element 578 represents the number data items 65 foundby the information storage and retrieval platform 12 based on the query“green” in “All categories.”

The above remarks may also apply to the cross aisle user interface andthe cross product user interface. The user interface elements 572 and574 representing the aisle domains 130 on the cross aisle user interface560 and the user interface elements 572 and 574 representing the productdomains 132 on the cross product user interface.

FIG. 28 is a diagram illustrating a department user interface 590,according to an embodiment. The department user interface 590 may begenerated based on the peak distribution 2 and includes a user interfaceelement 592 representing the “Home & Garden” department domain 128. Theuser interface 590 further includes user interface elements 594representing aisle domains 130 that may be organized under the “Home &Garden” department domain 128. The above remarks may also apply to theaisle user interface, the user interface element 592 representing theaisle domain 130 and the user interface elements 594 representing theproduct domains 132.

FIG. 29 is a diagram illustrating a product user interface 595,according to an embodiment. The product user interface 595 is shown toinclude user interface elements 596, 597, 598, 599, 601, and 603. Theuser interface element 596 represents a domain path that includes the“Apparel & Accessories” department domain 178, the “Women's Clothing”aisle domain 168, the “Shoes” product domain 166 and the number of dataitems 65 found based on the query “Women's Shoes.” The user interfaceelement 597 represents the aspect 206 “color.” The user interfaceelements 598 represent the values 208 “Black”, “Red”, and “Ruby” thatmay be associated with the aspect 206 “Color.” The user interfaceelements 599 represent counts of data items 65 that may be associatedwith the corresponding color. The user interface element 601 is apicture or graphic for a data item 65 that was found with the query. Theuser interface element 603 includes information that may be stored inthe data item 65 that was found with the query. The above remarks mayalso apply to the aisle user interface and the product user interface.

FIG. 30 shows a diagrammatic representation of machine in the exampleform of a computer system 600 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine operates as a standalone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in server-clientnetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a server computer,a client computer, a personal computer (PC), a tablet PC, a set-top box(STB), a Personal Digital Assistant (PDA), a cellular telephone, a webappliance, a network router, switch or bridge, or any machine capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that machine. Further, while only a singlemachine is illustrated, the term “machine” shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein.

The example computer system 600 includes a processor 602 (e.g., acentral processing unit (CPU) a graphics processing unit (GPU) or both),a main memory 604 and a static memory 606, which communicate with eachother via a bus 608. The computer system 600 may further include a videodisplay unit 310 (e.g., a liquid crystal display (LCD) or a cathode raytube (CRT)). The computer system 600 also includes an alphanumeric inputdevice 612 (e.g., a keyboard), a cursor control device 614 (e.g., amouse), a disk drive unit 616, a signal generation device 618 (e.g., aspeaker) and a network interface device 620.

The disk drive unit 616 includes a machine-readable medium 622 on whichis stored one or more sets of instructions (e.g., software 624)embodying any one or more of the methodologies or functions describedherein. The software 624 may also reside, completely or at leastpartially, within the main memory 604 and/or within the processor 602during execution thereof by the computer system 600, the main memory 604and the processor 602 also constituting machine-readable media.

The software 624 may further be transmitted or received over a network626 via the network interface device 620.

While the machine-readable medium 622 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single medium or multiple media (e.g., a centralizedor distributed database, and/or associated caches and servers) thatstore the one or more sets of instructions. The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies of the present disclosure. The term “machine-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, optical and magnetic media, and carrier wavesignals.

Thus, a method and system to communicate information has been described.Although the present disclosure has been described with reference tospecific example embodiments, it will be evident that variousmodifications and changes may be made to these embodiments withoutdeparting from the broader spirit and scope of the disclosure.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

We claim:
 1. A system including: a communication module to receive afirst query that contains a first constraint; a search index engine toretrieve a first plurality of data items from a database based on thefirst query and to generate a first distribution based on the firstplurality of data items, the first distribution to utilize a firstplurality of domains that are used to identify data items; a demand dataengine to generate a second distribution based on a plurality ofrequests to view a second plurality of data items; a coverage module togenerate a third distribution based on the first distribution and thesecond distribution; and a domain sort module to generate distributiondata to be included within an interface, the interface to include atleast one interface element that is positioned on the interface based onthe third distribution, the at least one interface element torespectively represent at least one domain.